home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / lang / c++-part2 / 13280 < prev    next >
Encoding:
Internet Message Format  |  1996-08-05  |  2.1 KB
  1. Path: howland.reston.ans.net!psinntp!psinntp!psinntp!psinntp!usenet
  2. From: grantp@usa.pipeline.com(Pete Grant)
  3. Newsgroups: comp.lang.c++
  4. Subject: Re: Coding Standards
  5. Date: 24 Mar 1996 17:05:10 GMT
  6. Organization: Kalevi, Inc.
  7. Message-ID: <4j3vc6$nrk@news1.h1.usa.pipeline.com>
  8. References: <4j2kgg$svj@sam.inforamp.net>
  9. NNTP-Posting-Host: 38.8.120.9
  10. X-PipeUser: grantp
  11. X-PipeHub: usa.pipeline.com
  12. X-PipeGCOS: (Pete Grant)
  13. X-Newsreader: Pipeline v3.5.0
  14.  
  15. On Mar 24, 1996 04:53:18 in article <Re: Coding Standards>,
  16. 'rmorin@inforamp.net (Randy Charles Morin)' wrote: 
  17.  
  18.  
  19. >In article <4iuu6k$6a6@druid.borland.com>, 
  20. >pete@borland.com (Pete Becker) wrote: 
  21. >>Unfortunately, if you don't follow guidelines like this, you will miss
  22. your  
  23. >>subsequent maintenance deadlines by many years. You'll spend all your
  24. time  
  25. >>tracking down mysterious failures that arise when you try to enhance the 
  26.  
  27. >>program, rather than spending time on the enhancements themselves. 
  28. > 
  29. >But if you follow these guidelines, your initial release will miss your  
  30. >subsequent maintenance deadlines.  You have to be reasonable in these  
  31. >situations.   
  32.  
  33. Right.  I will nearly always vote on the side of reasonableness. Seems  
  34. to me that since writing a trivial copy constructor can be implemented 
  35. in a matter of seconds, it's just a good habit to write one even if its 
  36. need isn't obvious at the time the class is in its initial stages of 
  37. development.  I doubt seriously if a few seconds, or even a minute or 
  38. two, spent at writing a copy constructor for all classes will cause 
  39. significant delays in product delivery. 
  40.  
  41. >        Why not make the standard that if you add a data member that may  
  42. >cause the default copy constructor to produce erroneous results, then 
  43. >make one explicitly?  This way you only have to write them when you need 
  44. >to and you have the same end result. 
  45. > 
  46. If we can rely on the maintenance programmer to think about the 
  47. problem, then OK, but that's not the real world.  IMHO, Pete Becker is 
  48. absolutely correct in this matter -- well, maybe he exaggerated just 
  49. a little bit... 
  50.  
  51. -- 
  52. Pete Grant 
  53. Kalevi, Inc. 
  54. Software Engineering & development
  55.